Expo는 React Native 개발을 위한 Framework이다. 원래 Framework란 편의성을 제공하지만, 정해진 규칙을 지켜야만 하며 제한되는 부분들도 존재할 수 있기에 사용하고 싶은 사람들만 사용하는 것이다. 그러나.. 내 생각에 이제 Expo는 Framework 수준이 아닌, 거의 React Native 그 자체라고 해도 무방하다고 생각한다. 편의성은 제공하되, 원한다면 native의 기능을 모두 이용할 수 있는 수준으로 판단되기 때문이다. 이런 언급이 가능한 이유는, React Native 자체에서 이를 인정하는 것으로 보여지기 때문이다. 실제 React Native 공식문서 Get Start 안내를 보면, 그냥 Expo를 사용한 개발을 추천하고 있다.

Expo(=React Native)가 크로스 플랫폼(하나의 소스 코드로 여러 운영체제(OS)나 기기에서 실행될 수 있도록 만드는 소프트웨어 개발 방식) Framework라는 것은 잘 알 것이다. 따라서 개발 자체는 React를 활용해 진행하면 되니 따로 언급할 것은 없다. 그러나 조금이라도 모바일 개발을 해본 사람이라면, AOS/IOS는 아예 다르다는 것을 알 것이며 특히 환경 설정(e.g. gradle, permission, plist)에서 골치 아팠던 경험이 있을 것이다. 고맙게도 이러한 역할을 Expo가 대행해주긴 하지만.. 안타깝게도 모든 부분이 대행되지는 않는다. 따라서 Expo가 native 대응을 위해 어떤 방법을 사용하는지를 알아야 할 것이며, 그를 통해 언제/어떠한 부분에서 부족할 것이기 때문에 개발자가 직접 개입을 해야하는지 깨달아야 한다.

---

Expo Go

아예 언급하지 않으려 했으나, 또 Expo의 가장 기초이기 때문에 기록만 하겠다. Expo Go는 테스트용 앱으로 스토에서 다운로드해 사용가능하다. Expo Go에는 "Expo sdk가 내장"되어 있기 때문에, 오로지 Expo sdk내부 기능만 사용해 개발한(어떠한 native 기능도 사용하지 않은) 앱의 경우 매우 빠르게 테스트가 가능하게 해준다. 이 경우가 만족되는 앱이라면, Production Build를 진행하더라도 Expo에서 알아서 처리될 것이기에 매우 편리할 것이다.

그러나.. 조금만 개발해 보아도 알 수 있다. native를 직접 건드리지 않고는 금새 벽에 부딪힐 것이다. 애초에.. Expo문서 위치는 기억나지 않지만, Expo도 앱 출시를 목표하며 개발한다면, 좋든 싫든 Development Build를 사용하는 방법으로 넘어가게 될 것이라고, 빠르든/늦든 넘어가게 되어있다고 말한다. 그러니 그런게 있다고만 알고, 사용할 생각은 말자.

Continuous Native Generation (CNG)

모든 프로젝트들이 그러하듯 기존 AOS/IOS앱 역시 유지/보수/확장이 필수적이다. 그리고 내 경험상 이는 AOS/IOS 같은 모바일 프로젝트에서 허들이 더 높다. 다양한 모바일 기기 대응 및 잦은 정책 변경 등의 이유로 인해 상시 주시하며 대응해주어야 하는 것이다. 그런데 Expo와 같은 크로스 플랫폼 앱은 다양한 플랫폼을 위한 대응을 모두 진행해야 한다. 알다시피 AOS와 IOS는 아예 다르다. 허들이 배로 높아지는 것이다.

그래서 Expo에서 제안하는 것이 Continuous Native Generation (CNG)이다. CNG는 Expo에서 제공하는 native 소스 자동 생성 기능이다. 기본적인 폴더 및 파일 구성을 물론이며 AndroidManifest.xml, Info.plist, build.gradle 등 핵심 네이티브 설정 파일에 필요한 코드나 설정을 자동으로 추가, 수정, 삭제하는 역할을 한다. 이러한 자동 생성을 통해, 개발자들은 플랫폼별/라이브러리 사용에 따른 프로젝트 설정 고민을 덜고, 앱 개발에만 집중할 수 있게 된다는 것이다.

Prebuild

앞서 언급한 CNG는 기능이라기 보다는 개념이다. 이 CNG 개념을 실제로 수행하는 명령어/기능이 바로 prebuild이다.

공식문서를 보거나, 여러 포스팅들을 보면 prebuild를 통해 "eject/native 코드 사용/Development Build로 변경" 등이 달성된다고 말하기도 한다. 물론 다 맞는 말이다. 하지만 나는 단순히 문자 그대로의 의미만 받아들이는게 좋다고 생각한다.

prebuild는 pre + build라는 뜻으로, 빌드를 하기전 사전 준비하는 행위이다. 단순히 "native 빌드를 하기 위한 사전 준비"를 한다는 것이다. 어떻게? 앞서 언급했듯 CNG 역할을 수행함으로서 사전준비를 수행한다. CNG 역할은? native 소스 코드 자동 생성이다.

실제 prebuild를 진행하면, 프로젝트에 android/ios 폴더가 생성될 것이다. 생성된 폴더들을 살펴보면 실제 native개발시 보던 파일들이 생성된 것이 확인된다. 즉 이 폴더/파일들을 생성하는 행위가 prebuild(=CNG 수행)인 것이다. 이 생성된 native 파일들이 추후 native build시 활용되는 것이다.

그러니 prebuild를 하면 native가 사용가능하다고 막연히 생각하고 있었다면... 맞기는 하지만 아니라고 말하겠다. prebuild는 그냥 native 폴더를 생성해 빌드를 준비하는 행위일 뿐이다.

그럼 prebuild는 언제 사용되어야 할까? 그야 물론 빌드하기 전이다. 그럼 매번 빌드하기 전에 사용해주어야 할까? 아니다. prebuild를 통해 얻는 것은 native 소스이다. 그러니 앱에 추가된 native 기능이 없다면, 이전에 prebuild된 결과물을 그대로 사용하면 된다. 반대로 앱에 추가된 native 기능들이 있다면? prebuild 결과물은 프로젝트내에 폴더로서도 보이는 고정된 산출물이다. 이것이 마법같이 바로 변경되지 않는다... 이런 경우에 prebuild를 다시 사용해, 새로운 native 소스들을 생성해주어야 하는 것이다. 이때는 기존 소스들을 지우기 위해 --clean 과 함께 사용토록 하자.

Config Plugin

그렇다면 우리는 필요할때 한번씩 prebuild를 사용함으로써, 더이상 native 소스, 환경설정들은 신경쓰지 않아도 되는 것일까? 그럴 수도 있지만.. 대부분의 경우 안타깝게도 그렇지 못하다. Expo는 훌륭한 개발도구이지만, 신이 아니다. 세상에 존재하는 모든 라이브러리 사용, 변경되는 환경설정 방법 등을 대응해줄 수는 없다.

이런 경우에 사용하는 것이 config plugin이다. 여타 개발을 경험한 사람들은 플러그인? 라이브러리나 sdk추가하라는 것인가? 라고 생각할 수 있겠지만, 아니다. 그냥 프로젝트에 설정을 위한 스크립트를 추가하는 것이다.

기본적으로 prebuild는 app.json 파일 및 package.json 파일 등을 참조해서 native 소스파일을 생성한다. 이때 config plugin을 사용한다면 해당 prebuild(CNG) 로직에 변경/참여 할 수 있다. 직접 native 소스(android/ios폴더 내 스크립트)를 변경하지 않고도, prebuild되어 나온 결과물에 영향을 줄수 있다는 것이다.

Manual native update

prebuild를 완료하면 프로젝트에 android/ios 폴더(native 소스)가 생성된다고 하였다. 추후 native 업데이트가 필요할 때, 이 소스를 직접 수정하면 어떻게 될까? 문제될 것은 없지만, Expo의 CNG 기능을/생태계를 벗어나는 행위라는 것은 명확히 인지하고 있어야 한다.

계속 언급하지만 CNG는 prebuild를 진행해 native소스를 생성해주는 기능이고, native 소스에 변경이 필요할시 config 등의 설정을 마친 후 다시 prebuild를 진행하는 방식이다. 이때 Expo에서도 기존의 소스와 충돌이 있을지도 모르니, 기존 소스를 지우고 다시 만들라는 --clean 명령어와 함께 사용하길 권장한다. 만일 config 등의 설정 없이 native 소스를 직접 수정하였는데, 추후 prebuld를 다시 진행한다면? 직접 수정한 내용들은 모두 날아가는 것이다.

따라서 직접적인 native 소스 코드 수정은 config 설정 등으로 도저히 목표가 달성되지 않을 때 "사용해도 되지만", 변경한 후에는 CNG 생태계를 벗어난 것이므로 절대 prebuild를 해서는 안된다.

Development Build

개발자 빌드는 말그대로 개발을 위해 빌드된 산출물이다. AOS 앱을 빌드하면 apk, aab 파일을 얻을 수 있지 않나? 그냥 그거다. 앱 개발을 위한 apk 파일을 의미하는 것이다.

당연하다고 생각할 수 있는 말을 왜 저리 적어놓았냐면.. 내 생각에는 공식 문서는 물론 여러 포스팅들에서 혼동되기 딱 좋게 표현들이 많다는 것이다. 문제는 그게 또 틀린 말까지는 아니라는 점이다. Expo로 native 개발을 하려면 development build를 해야한다거나, prebuild를 통해 development build를 달성할 수 있다거나, 거꾸로 development build가 prebuild를 사용하는 것이라고 한다거나.. 다 기억이 안나는데 그 밖에도 참 많다. 뭐랄까 읽다보면 development build는 빌드가 아니라 어떤 개념을 의미하는 것가 싶고, 이게 뭐지 싶기도 했다.

A development build is a debug build of your app that contains expo-dev-client library.

위 문장이 정확히, Expo 공식문서의 표현이다. expo-dev-client라는 라이브러리를 탑재한 오류 검출용도의 빌드라는 것이다. 그러니 어렵게 생각할거 없이 그냥 apk파일이라고 생각하면 된다.

그럼 왜 prebuild 및 native 개발이라는 개념과 계속 연계되어 소개될까? 명확지는 않지만 이는 잠깐 언급한 Expo Go 때문인 것으로 추측된다. Expo Go를 활용하는(= Expo sdk만 사용하는) 앱의 경우, native 소스를 작성/수정할 필요가 없다. 이런 앱도 prebuild를 진행하고 development build를 만들 수 있겠지만, 굳이? 낭비이기 때문에 할 이유가 없다. 즉, 애초에 development build가 필요한 경우 자체가, Expo Go 생태계를 벗어난 상황이라는 것이다. 그리고 Expo Go 생태계를 벗어난 상황이라는 것은 native 수정이 필요한 상황이라는 의미이다.

Expo Go라고 prebuild를, native 소스를 사용하지 않는다고 생각지 말자. 애초에 React native 앱이라는 것은 빌드가 되려면 native 소스가 필요하다. Expo Go를 활용한다는 건 알아서 모든 native 처리를 한다고 이해하면 편하다.

development build 사용한 개발 방법은 다음과 같다. 먼저 만들어진 개발 빌드를 에뮬레이터, 실제 디바이스 등에 넣고 설치한다. 앱이 생성될 것이며 이를 실행하면 된다. 그러나 그냥 동작하지는 않고, 개발 서버(metro 서버)와 통신이 연결되어야 한다. 통신 연결에는 여러 방법이 있지만 내가 사용하는 방법은 다음과 같다.

• 로컬 서버 실행 (npm start), QR코드 생성
• (실제 디바이스인 경우) 로컬 네트워크(와이파이) 접속, 네트워크 환경을 개발 서버와 같은 것으로 맞춤
• 앱을 실행 후, QR 코드 스캔

공식 문서에 따르면, 로컬 네트워크가 아니어도 연결될 수 있다는 것 같은데.. 아직 시도해본 적은 없다

Expo Application Services(EAS)

그럼 development build를 생성하려면 어떻게 해야할까? 일반적인 프로젝트처럼 개인 PC(로컬)에서 진행할 수도 있다. 그러나 나는 EAS 사용을 선호한다.

EAS는 Expo가 제공하는 서비스로 여러 기능들이 존재하는 것으로 알고 있다. 아마 많이 알려진 것이 스토어에 업로드하는 기능과 build 기능일 것으로 추측된다. 그 외에도 기능이 더 있는 듯 하지만.. 나도 모른다. 사실 나는 아직 스토어 업로드 기능도 써보지 못했다. 언젠가 업로드할 앱이 생겨야 도전해볼 듯 싶다.

어쨌든, 나는 EAS를 통한 Build를 선호한다. 왜? 이유는 간단하다. 나의 개발환경은 window이고 mac은 없다는 것이다. 이 환경에서 IOS 빌드를 하기 위해 취할 수 있는 가지 수가 많지 않다. 그마저도 썩 좋은 방법은 아니라고 판단되고. 진짜 X 같은 사과놈들.. 어쨌든 이런 상황이기에 EAS build는 내게 그저 한줄기 빛이었다. IOS가 아닌 빌드라면 로컬로 해도 되겠지만, 굳이 여러 방법을 활용하고 싶지 않았기에, 나는 development build 포함, 모든 build는 EAS를 활용한다.

대부분의 빌드는 버튼 딸각, 한 줄의 명령어로 시작되듯 EAS를 활용한 빌드도 마찬가지이다.

eas build --platform android|ios|all
eas build --platform android|ios|all --profile development 

직관적으로 알겠지만, 위는 일반 production 빌드를, 아래는 development build를 요청하는 것이다.

사실 이 EAS build를 사용하기전, 조금 설정해야 하는 부분이 있다. 매우 간단하니 공식문서를 활용하자.